home *** CD-ROM | disk | FTP | other *** search
- Hey Thomas. Thanks for getting back to me; the problem persists,
- however. Here's what I have been able to figure out:
-
- When I run Dave Brooks' NLPD manager only, I get the results that you
- mentioned, namely that WLPRSPL spools the file once, and everything looks
- fine. When I run BOTH the NLPD and the SPOOL*.EXE, though, WLPRSPL
- spools over and over and over. The app that I am testing with is just
- Microsoft Word; I compose a small document, and then try to print it.
-
- Now, when you select a new printer through Microsoft Word, it selects
- that printer as the new system default. Thus, when I select the queue
- for WLPRSPL to print to through Word, that queue becomes the new default
- for ALL apps, and this fact is reflected in the WLPRSPL dialog window
- with an asterisk next to the name of the queue, instead of a greater-than
- sign. Here's what I have figured out: it is ONLY when the queue to which
- WLPRSPL is spooling is the system default that it exhibits the endless
- spooling/no printing problem. In order to verify this, what I did was:
- print a document through Word to the queue, quit Word, go to the Windows
- control panel for Printers, and change the default queue back to my
- direct connection. Guess what? WLPRSPL printed. SO, the problem
- appears to be that WLPRSPL is choking on printing to the system default
- printer/queue. Another, independent verification of this is the fact
- that I can use WLPRSPL to print from Notepad without problems; Notepad
- does not change the system default when you select your printer through
- it, so it SHOULDN'T have a problem.
-
- I hope that this helps; if any of it is confusing (which I am sure is the
- case), feel free to get back to me.
-
- Talk to you soon!
-
- Jason
-
- Jason Levine +---------------------------+ Jason Levine
- 318 Schapiro Hall | Send electronic mail to: | 1035 Park Avenue
- 605-15 West 115th Street | Jason.Levine@columbia.edu | Apartment 2B
- NY NY USA 10025 +---------------------------+ NY NY USA 10028
- From news@bigblue.oit.unc.edu Wed Mar 9 16:44:32 1994
- Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
- id AA11227; Wed, 9 Mar 1994 12:28:12 -0500
- Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
- id AA15778; Wed, 9 Mar 1994 12:14:06 -0500
- Received: from GATEWAY by bigblue with netnews
- for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
- To: winsock@sunsite.unc.edu
- Date: Wed, 9 Mar 1994 16:44:32 GMT
- From: w-rolph@ds.mc.ti.com (Don Rolph)
- Message-Id: <w-rolph.345.000BBE59@ds.mc.ti.com>
- Organization: pan.mc.ti.com
- Sender: ses
- References: <1994Mar1.054449.17670@usage.csd.unsw.OZ.AU>
- Subject: Re: MS TCP/IP is not necessarily a memory hog
-
- In article <1994Mar1.054449.17670@usage.csd.unsw.OZ.AU> S.Yussof@unsw.EDU.AU writes:
- >From: S.Yussof@unsw.EDU.AU
- >Subject: MS TCP/IP is not necessarily a memory hog
- >Date: Tue, 1 Mar 1994 05:44:49 GMT
-
- >MS TCP/IP need not be a memory hog.
- >-----------------------------------
-
- >Modules using memory below 1 MB:
-
- > Name Total = Conventional + Upper Memory
- > -------- ---------------- ---------------- ----------------
- > MSDOS 17,101 (17K) 17,101 (17K) 0 (0K)
- > HIMEM 1,168 (1K) 1,168 (1K) 0 (0K)
- > EMM386 3,120 (3K) 3,120 (3K) 0 (0K)
- > COMMAND 3,696 (4K) 3,696 (4K) 0 (0K)
- > PROTMAN 2,560 (3K) 2,560 (3K) 0 (0K)
- > UMB 960 (1K) 272 (0K) 688 (1K)
- > TCPTSR 52,576 (51K) 272 (0K) 52,304 (51K)
- > TINYRFC 2,864 (3K) 272 (0K) 2,592 (3K)
- > NMTSR 6,144 (6K) 6,144 (6K) 0 (0K)
- > EMSBFR 1,456 (1K) 272 (0K) 1,184 (1K)
- > DNR 1,936 (2K) 1,936 (2K) 0 (0K)
- > SOCKETS 11,584 (11K) 272 (0K) 11,312 (11K)
- > MOUSE 24,608 (24K) 272 (0K) 24,336 (24K)
- > SETVER 624 (1K) 0 (0K) 624 (1K)
- > ANSI 4,240 (4K) 0 (0K) 4,240 (4K)
- > RAMDRIVE 1,232 (1K) 0 (0K) 1,232 (1K)
- > IFSHLP 3,904 (4K) 0 (0K) 3,904 (4K)
- > DOSKEY 4,144 (4K) 0 (0K) 4,144 (4K)
- > PROTMAN 400 (0K) 0 (0K) 400 (0K)
- > NI6510 22,096 (22K) 0 (0K) 22,096 (22K)
- > NDISHLP 1,440 (1K) 0 (0K) 1,440 (1K)
- > TCPDRV 1,328 (1K) 0 (0K) 1,328 (1K)
- > NEMM 2,384 (2K) 0 (0K) 2,384 (2K)
- > Free 641,984 (627K) 617,616 (603K) 24,368 (24K)
-
- >Memory Summary:
-
- > Type of Memory Total = Used + Free
- > ---------------- ---------- ---------- ----------
- > Conventional 655,360 37,744 617,616
- > Upper 158,576 134,208 24,368
- > Reserved 393,216 393,216 0
- > Extended (XMS)* 7,181,456 1,545,360 5,636,096
- > ---------------- ---------- ---------- ----------
- > Total memory 8,388,608 2,110,528 6,278,080
-
- > Total under 1 MB 813,936 171,952 641,984
-
- > Total Expanded (EMS) 7,667,712 (7,488K)
- > Free Expanded (EMS)* 5,767,168 (5,632K)
-
- > * EMM386 is using XMS memory to simulate EMS memory as needed.
- > Free EMS memory may change as free XMS memory changes.
-
- > Largest executable program size 617,296 (603K)
- > Largest free upper memory block 12,288 (12K)
-
- This matches very closely my results of about 9.6K utilized by the microsoft
- tcp/ip modules.
-
- Well said my man (or should I say g'day mate!)
-
-
-
- Regards.
-
- Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263
- From news@bigblue.oit.unc.edu Wed Mar 9 12:02:30 1994
- Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
- id AA15360; Wed, 9 Mar 1994 12:58:11 -0500
- Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
- id AA28094; Wed, 9 Mar 1994 12:35:32 -0500
- Received: from GATEWAY by bigblue with netnews
- for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
- To: winsock@sunsite.unc.edu
- Date: 9 Mar 1994 12:02:30 GMT
- From: ultima@cc.nctu.edu.tw (smile)
- Message-Id: <2lkdsm$bf0@debbie.cc.nctu.edu.tw>
- Organization: Computer Center, National Chiao-Tung University, Taiwan
- Sender: ses
- Subject: How to complie?
-
- I get a program named ws_ftp. Their are winsock.lib whose length is 1024.
- I load ws_ping.prj in Borlnd C++ 4.0. Compling is sucessful. But linking
- failed. Why? How to link winsock.lib or winsock.dll? It shows socket,sento,
- ,etc are undefined symbol.
-
- Thanks.
-
-